# Нефункциональные требования
## Описание
При разработке новой функциональности часто приходится делать выбор – сделать ли её более производительной или более поддерживаемой, более надёжной или более безопасной. При поддержке уже написанной системы тоже встают подобные вопросы, например, что именно кроется под понятием "высокая доступность". Разобраться в этом помогают описанные нефункциональные требования.

Нефункциональные требования – это чёткие критерии того, **как** система должна работать, в отличие от функциональных, которые описывают, **что** система должна делать. Давайте посмотрим на пример.
> API метод должен возвращать список ресторанов в короткой форме: id, название, адрес

Это функциональное требование, оно описывает поведение системы.

> API метод должен отдавать данные не более чем за 200ms на 95 перцентиле и не более чем за 500ms на 99 перцентиле.

А это уже нефункциональное требование, которое описывает определённый атрибут качества – performance.

## Почему ветка важна?
Для тимлида:
- Возможность описать поведение системы, за которую он отвечает, в чётких параметрах, и понимать, соответствует ли она им

Для команды:
- Неопределённые желания заказчиков вроде "работает быстро" преобразованы в чёткий список требований
- Проще достигать согласия при спорных вопросах проектирования – вместо субъективных домыслов для аргументации используются конкретные требования

## Что будет, если её не делать?
- Если обоснованные нефункциональные требования отсутствуют на этапе проектирования, то в будущем может быть невозможно начать им соответствовать без полного переписывания
- Система может получиться медленной, небезопасной и не соответствующий всем прочим атрибутам качества
- Архитектурные решения будут приниматься не на основе того, как должен работать продукт, а на основе личных предпочтений команды
- Сложно настроить разумный мониторинг, и понять, что является желаемым поведением

## На кого может быть делегирована?
На специалиста по контролю качества, архитектора.

## Примеры поведения
### Примеры плохого поведения
- Атрибуты качества не описаны в виде нефункциональных требований
- Нефункциональные требования взяты из головы и не подтверждены реальным смыслом и необходимостью
- Нефункциональные требования выписаны на бумажку, но никак не проверяются на работающей системе
- Нефункциональные требования не учитываются при тестировании

### Примеры хорошего поведения
- Для разрабатываемой системы определены требуемые атрибуты качества
- На основе сравнения с конкурентами, изучения поведения пользователей и требований соседних подсистем определены конкретные нефункциональные требования
- Проверка на соответствие нефункциональным требованиям проводится с помощью синтетических тестов в CI
- Production мониторинг ориентируется на список нефункциональных требований
- На всех архитектурных ревью система нефункциональных требований используется для принятия решений

## Способы прокачки

## Консультации
- [Telegram-чат TL Bootcamp](https://tlinks.run/tlbootcamp)

## Теория
### Статьи
- [Software Quality Attributes, Non-Functional Requirements and Better Software Architecture](https://medium.com/@andreigridnev/non-functional-requirements-quality-attributes-and-better-software-architecture-855425310e60)
- [Systems and software engineering — Systems and software Quality Requirements and Evaluation](https://www.iso.org/obp/ui/#iso:std:iso-iec:25010:ed-1:v1:en)
- [12 software architecture quality attributes](https://syndicode.com/2018/05/03/12-software-architecture-quality-attributes/)
